“Transactions” are a feature offered by most modem enterprise-class databases to ensure data integrity is maintained when data is modified. Maintaining data integrity protects the quality of the data that organizations rely upon. When organizations generate reports, for example, when a bank generates an online account summary, or engages in any other data-driven procedure, they want to know that the information they are working with is correct and is not subject to damage due to failure of any parts of the system, either hardware or software.
Database transactions are said to have “ACID” properties:
Atomic—All statements in a transaction either complete successfully, or they are all rolled back. The task that the set of operations represents is either accomplished or not, but more importantly it is not left half-done, to the detriment of data integrity.
Consistent—All data touched by the transaction is left in a logically consistent state. For example, if inventory numbers were decremented in one table, there has to be a related order that consumed that inventory. The inventory can't just disappear.
Isolated—The transaction must affect data without interfering with other concurrent transactions, or being interfered with by them. This prevents transactions from making changes to data based on uncommitted information, for example changes to a record that are subsequently rolled back. Most databases use locking to maintain transaction isolation.
Durable—The data changes enacted by the transaction are permanent, and will persist through a system failure.
One classic example for demonstrating the need for transactions is submitting an order to an order entry system. Consider a company that wishes to check a customer's credit level, create an order record, create order line item records, decrement the order items from inventory, create a ship request, and any number additional related steps. If one or more of those steps fail but the rest succeed, the company can end up with inconsistent data in the form of orphaned records, unreliable inventory numbers, and so forth. Using transactions appropriately prevents this from occurring.
Note that the steps in the above example can be described as a workflow. A number of discrete workflow tasks, or steps, may each contribute to the workflow. Some of the steps may generate data that will be used to update a database, while other steps may simply perform temporarily needed functions. The question arises, especially for longer workflows, which steps should be included in a transaction? More specifically, which of the steps should either commit or be rolled back as a group? At present, workflow design and execution software is not arranged to easily delineate the transactional grouping of workflow steps. While individual workflow steps can be associated, one-by-one, with a particular transaction, this leaves workflow designers no easy way to visualize and understand the relationships between the steps in a workflow vis-á-vis involvement in database transactions.